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ABSTRACT 


It  has  become  apparent  that  in  order  for  an  AUV  to  be  a  more  reliable  self- 
sufficient  system,  it  must  have  on-line  failure  detection  and  resolution  capability.  In 
support  of  this  the  AUV  must  have  reconfigurable  systems  so  as  to  be  able  to  take 
corrective  action  against  resolvable  failures.  A  simulator  has  been  designed  using 
SIMULINK  in  order  to  analyze  failure  modes  associated  with  the  NPS  Phoenix  AUV 
steering  system.  The  analyses  of  these  failure  modes  have  been  used  to  identify  possible 
signals  for  steering  system  fault  detection.  Finally,  a  rule  based  algorithm  was  developed 
which  can  be  converted  into  a  format  that  ultimately  could  be  implemented  in  a  fuzzy 
logic  set,  for  later  insertion  into  the  Phoenix  tactical  level  software.  This  methodology 
will  be  applied  to  the  Navy's  UUV. 
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I.  INTRODUCTION 


A.  GENERAL  BACKGROUND  AND  LITERATURE 

Over  the  past  decade  more  and  more  research  has  been  devoted  to  the 
development  of  Autonomous  Underwater  Vehicles  (AUV's).  The  potential  for  AUV's 
is  large  and  eventually,  even  Remotely  Operated  Vehicles  (ROV's)  will  incorporate 
some  of  the  new  AUV  technology.  The  potential  commercial  and  military  uses  for 
AUV's  far  out  number  those  of  ROV's,  not  to  mention  the  benefits  it  can  provide  to 
ocean  science  research.  Simply  put,  AUV's  are  our  future. 

Technology  of  AUV's  has  come  a  long  way  over  the  last  decade.  However, 
much  research  must  still  be  conducted  in  all  areas  of  AUV  technology.  Some  of  the 
more  recent  works  are  cited  here  to  show  the  broad  spectrum  of  study  that  is  still 
ongoing.  Healey  and  Lienard  (1993)  have  shown  that  a  multivariable  sliding  mode 
autopilot  based  on  state  feedback,  designed  assuming  decoupled  modeling,  is  quite 
satisfactory  for  the  combined  speed,  steering,  and  diving  response  of  a  slow  speed 
AUV.  Marco  and  Healey  (1996)  have  demonstrated  a  method  to  navigate  an 
autonomous  underwater  vehicle  in  a  local  area  using  an  acoustic  sensor  for  position 
information  derived  from  feature  detection.  Further  developments  have  been  achieved 
by  Healey,  et  al.  (1994)  in  hover  control  behavior  using  the  ST1000  and  ST725  high 
frequency  sonars  to  provide  data  about  the  environment.  Byrnes,  et  al.  (1996)  has 
proposed  a  tri-level  control  system  architecture  called  the  Rational  Behavior  Model 
(RBM)  as  an  approach  to  autonomous  and  automatic  control  of  systems.  A  work 
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which  describes  the  advantages  of  AUV's  over  ROV's  or  manned  submarines  was 
written  by  Marco  (1996),  in  which  he  designed  and  verified  a  working  hybrid  control 
system  combining  mission  management  with  robust  motion  controllers. 

An  area  which  is  now  receiving  more  focused  attention  is  Failure  Modes  and 
Effects  Analysis  (FMEA).  This  is  because  it  is  becoming  more  readily  apparent  that 
in  order  for  an  AUV  to  be  a  totally  self-sufficient  system,  it  must  have  an  on-line 
failure  detection  and  resolution  algorithm.  This  algorithm  must  work  in  tandem  with 
an  AUV  whose  systems  are  reconflgurable.  The  scope  of  this  work  takes  a  very  small 
step  towards  this  goal.  Its  purpose  is  to  design  an  effective  failure  detection  and 
resolution  algorithm  for  one  subsystem  (steering)  of  the  NPS  Phoenix.  The  Phoenix  is 
an  underwater  vehicle  used  by  the  Naval  Postgraduate  School  to  conduct  AUV 
research. 

Previous  literature  pertinent  to  this  particular  area  of  research  is  very  abundant. 
A  brief  summary  of  some  basic  fault  detection  methods  along  with  some  examples  can 
be  found  in  Isermann  (1984).  The  examples  provided  were  detecting  faults  in  an 
electrically  driven  centrifugal  pump  and  leak  detection  for  pipelines.  Healey  (1993) 
discusses  the  use  of  both  batch  least  squares  and  Kalman  Filters  for  system  parameter 
identification  as  a  means  to  detect  a  change  in  performance.  Bell,  et  al.  (1992)  has 
developed  a  tool  that  automates  the  reasoning  portion  of  an  FMEA.  The  prototype  has 
been  created  and  successfully  passed  a  test  and  evaluation  program.  A  program  which 
automates  the  prediction  of  the  effect  of  failure  modes  for  electrical  systems  has  been 
developed  by  Hunt,  Price  and  Lee  (1993).  This  program  is  called  FLAME  (Functional 
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Level  Analysis  of  failure  Modes  and  Effects).  Finally,  Healey  (1992)  addresses  the 
use  of  Kalman  Filters  and  Artificial  Neural  Networks  to  provide  the  detection,  and 
isolation  of  impending  system  failures. 

For  some  time  the  Navy  has  funded  the  development  of  software  tools  for 
performing  automated  on-line  system  fault  detection.  It  has  been  agreed,  however,  that 
too  much  detail  can  lead  to  unwieldy  systems.  Also,  for  a  useful  automated  diagnostic 
system  to  be  able  to  improve  the  reliability  of  AUV's,  only  those  problems  that  can  be 
mitigated  during  a  mission  need  to  be  identified.  Therefore,  this  work  concentrates  on 
"subsystem  level"  fault  detection  rather  than  "component  level"  detection.  The 
difference  lies  in  the  granularity  established  by  the  system  models  used  as  the 
detection  basis.  In  principle,  a  diagnostic  system  is  only  able  to  detect  faults  at  the 
level  of  its  design  model  basic  granularity.  For  instance,  if  a  subsystem  or  component 
(G)  is  modeled  by  its  input,  output  and  disturbance  signals  (Figure  1.1),  we  can,  under 
some  conditions  relating  to  the  observability  of  the  system  model,  infer  the  satisfactory 
operation  of  the  subsystem  (G)  with  regard  to  a  desired  behavior.  If  a  model  based 
filter  is  proposed  for  the  control  signal  (eQ)  such  that  Gc  is  a  model  for  G,  changes  in 
G  from  any  source  are  detectable  through  the  input/output  signals  (u,  Y)  and  in 


particular  the  servo  error  (es  =  Ycom 


^ )  and  the  observer  error  (eQ  =  Y  - 


input  signal  (u)  is  determined  by  the  system  controller  (C). 
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B.  SCOPE  OF  THIS  WORK 

The  driving  force  of  this  thesis  is  threefold:  1)  Earlier  work  by  Bahrke  (1992) 
broke  down  the  Phoenix  AUV  into  separate  subsystems  and  generated  equations  that 
could  be  used  to  model  these  systems.  The  work  in  this  thesis  seeks  to  show  that 
these  equations  can,  with  reasonable  accuracy,  model  the  AUV  steering  system  using  a 
CAD  program  such  as  SIMULINK  in  MATLAB.  2)  The  simulator  designed  in  this 
work  is  used  to  conduct  an  intensive  study  of  all  the  possible  failure  modes  that  could 
be  related  to  the  steering  system.  3)  Armed  with  the  knowledge  provided  by  all  the 
simulations,  an  algorithm  is  developed  whose  purpose  is  to  detect  steering  system 
failures  and  reconfigure  the  system  (when  necessary)  to  operate  efficiently,  or  abort  the 
mission. 

Chapter  II  focuses  on  the  design  of  an  effective,  user  friendly,  FMEA  simulator 
geared  towards  the  NPS  Phoenix  AUV  (Figure  1.2)  steering  system.  It  was  very 
important  in  this  chapter  to  ensure  that  the  vehicle  was  accurately  modeled.  However, 
major  emphasis  was  given  toward  user  friendliness,  because  future  work  in  this  area 
will  require  the  ability  to  operate  and  possibly  change  the  simulator. 

Chapter  III  categorizes  the  various  failure  modes  that  could  occur,  simulates 
them  and  places  these  results  in  tabular  form  to  help  determine  their  distinguishing 
features.  Further  study  is  done  to  show  which  failure  modes  can  be  ignored  (small 
effect  on  system),  which  ones  must  be  prevented  at  all  costs  (either  devastating  to  the 
system  or  undetectable),  which  ones  will  require  system  reconfiguration  to  ensure 
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continued  effective  operation  and  which  ones  will  require  a  mission  abort.  How  the 
steering  system  should  be  reconfigured  for  various  failures  is  also  addressed.  The 
ultimate  goal  of  developing  a  useful  algorithm  for  failure  detection  and  resolution  was 
then  realized. 
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Nava1  Postgraduate  School  'Phoenix'  AUY.  From  Marco  (1996). 
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n.  DESIGN  OF  A  STEERING  SYSTEM  FMEA  ANALYSIS  TOOL 


A.  INTRODUCTION 

The  purpose  of  this  chapter  is  to  show  the  steps  taken  in  the  design  of  a 
steering  system  failure  modes  and  effects  analysis  (FMEA)  tool.  This  FMEA  tool  is 
specifically  designed  to  simulate  (using  MATLAB/SIMULINK)  the  response  of  the 
NPS  Phoenix  AUV  to  various  failures  that  could  occur  in  its  steering  system. 
Naturally,  the  design  had  to  be  carried  out  in  steps.  The  dynamics  of  the  vehicle  in 
response  to  steering  system  commands  had  to  be  simulated  first.  Once  that  was 
achieved,  a  PD  controller  was  designed,  and  then  a  state  estimator.  Finally,  a  method 
of  artificially  inserting  failures  into  the  system  was  added  to  the  simulation.  The 
overall  block  diagram  is  shown  in  Figure  2.1.  Figure  2.2  may  be  useful  in 
understanding  the  geometry  and  axes  definitions  of  the  AUV. 


B.  VEHICLE  DYNAMICS  RESPONSE  TO  SPEED  AND  RUDDER  INPUTS 


It  was  shown  by  Fossen  (1994)  that  the  response  of  the  vehicle  to  speed  and 
rudder  inputs  can  be  reduced  to  a  force  equation,  a  moment  equation  and  the  three 
Euler  equations  relating  • ,  y  and  ,j,.  It  was  assumed  that  the  vehicle  operates  in 

A  I 


level  flight  without  roll,  and  that  body  drag  forces  are  negligible.  The  resulting 
equations  are: 
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my + mxj  -Yf-  Y.v  -  -mur  +  Ypr  +  Yjuv  +  u2(Y6J>rb  +  Yt^J 
1/  +mxGv -Nr -NJ>  =  -mx^r  +Nrur  +Nvuv+u2(N6  brb  +Nb  bK) 

X=mcosT  -vsinY 
Y=usmx¥  +vcosT 
T=r 


The  following  additional  assumptions  were  made  by  Bahrke  (1992): 

1 .  The  bow  and  stem  rudders  operate  with  equal  magnitudes  of  deflection  but 
opposite  direction  (8rs  =  -8rb). 

2.  The  size  and  shape  of  the  bow  and  stem  rudders  is  identical  (Ys  =  Y5rb  = 
YSJ. 

3.  From  vehicle  geometry  NSrb  =  0.283LYS  and  N5rs  =  -0.377LYS. 

Along  with  these  assumptions  the  two  rudder  inputs  (8rs,  Srb)  were  divided  up  into  four 
inputs  (8^,  8ks,  8^,,,  8^)  for  simulation  purposes.  This  allows  any  one  rudder  input 
to  be  altered  for  the  purpose  of  rudder  failure  insertion  and,  ultimately,  the  analysis  of 
the  effects  of  that  failure  on  the  vehicle.  Using  the  above  relations  and  rearranging, 
the  force  and  moment  equations  can  be  written  as  follows: 

(m  -  Y.)y  +  (j mxG  -  Yr)r  =  Fv«v  +  ( Yr  -  m)ur + 0.5  u 2  5^(6^  +  6  w 

(mxG-Nv)v+{Iz-Nt)r  = 

Nvuv +(Nr -mxG)ur  +  0.5L« ^[0.283(5^  +  5lrb)  -0.377(8^  +  6  J] 

In  order  to  model  the  force  and  moment  equations  above,  it  is  necessary  to 
determine  the  values  of  the  constants  and  coefficients  that  appear  in  the  equations. 
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Appendix  A  contains  the  values  of  these  constants  and  coefficients  (Bahrke,  1992). 
However,  the  coefficients  are  in  their  dimensionless  form.  Thus  it  is  necessary  to 
dimensionalize  the  coefficients  such  that  each  term  in  the  force  equation  has  units  of  lbs. 
and  each  term  in  the  moment  equation  has  units  of  lbs.-ft  The  coefficients  of  the 
Phoenix  AUV  were  dimensionalized  by  multiplying  each  one  with  the  appropriate  form 
of  0.5 pu  mL  ”  (Healey,  1996).  The  resulting  equations  were  rearranged  such  that  the 
force  equation  was  solved  for  v  and  the  moment  equation  was  solved  for  r  .  They  are 
shown  here  in  their  final  form  for  simulation: 

v  =  -0.190597r  -0.20901mv  -0.5 1091  ur  +  0.01  1525m  \burh  +6[rb  +  6urs  +  6,rj) 
r  =  -0.09263v  -0.19988«r  +0.0408872«2[0.283(6ar6  +6/rft)  -0.377 (S„„  +S/„)] 

The  above  two  equations  along  with  the  equation  for  Y  were  used  to  form  the  Steering 
block  of  Figure  2.1. 

The  steering  system  model  is  shown  in  Figure  2.3.  The  inputs  to  the  model  are 
the  forward  speed  of  the  vehicle  (u)  and  the  four  rudder  deflections  (S(  )).  Speed  is  varied 
by  changing  the  output  value  of  the  Speed  block  of  Figure  2. 1 .  The  rudders  get  their 
commands  from  the  output  of  the  PD  controller  block.  The  outputs  of  the  model  are 
sway  velocity  (v),  yaw  rate  (r)  and  heading  angle  (Y).  The  last  things  added  to  the  model 
were  two  files  containing  random,  low  frequency,  system  noise  (noise  1. mat  and 
noise2.mat).  These  system  noise  files  were  added  to  the  right  sides  of  the  v  and 
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j.  equations.  They  simulate  the  added  forces  and  moments  that  occur  naturally  due, 

mainly,  to  wave  action  in  the  water.  Appendix  B  contains  the  MATLAB  program 
(obtained  from  professor  Healey)  used  to  generate  these  system  noise  files. 

The  XY  output  block  of  Figure  2.1  was  created  so  that  a  graph  of  the  vehicle's 
XY  position  could  be  plotted.  This  graph  further  aids  in  understanding  the  vehicle's 
response  to  various  failure  modes.  The  internals  of  this  block  are  shown  in  Figure  2.4. 
The  XY  output  is  plotted  as  a  function  of  the  inputs  u,  v  and  x¥. 

C.  PD  CONTROLLER  DESIGN 

In  order  to  design  a  PD  controller  the  equations  for  ^  and  ^  had  to  be 
linearized  about  a  single  velocity  and  then  placed  in  their  state  space  form: 

x  ~Ax  +  B5 

com 

The  form  that  is  shown  above  requires  that  the  four  rudder  inputs  be  combined  into 
one  commanded  rudder  input  (Scom).  The  controller  design  involves  pole  placement  to 
find  a  1x3  matrix  (k)  such  that  the  control  law  is  8com  =  -kx.  Linearization  was  done 
about  u  =  1  ft/s  and  the  3x3  A  matrix  had  one  eigenvalue  at  zero  and  the  other  two 
were  complex  with  real  parts  at  -0.1840.  Given  these  particular  eigenvalues  the  three 
poles  were  placed  at  about  -0.2  to  approximately  match  the  open  loop  poles  at  - 
0.1840.  The  resulting  gain  matrix  was  k  =  [0.3587  4.29  0.6949],  which  produced  the 
following  control  law: 
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6_om  =  -0.3587v  -4.29r  -0.6949T 

com 


There  are  two  problems  with  the  above  control  law.  The  first  problem  is  that  it 
is  based  on  a  model  that  was  linearized  about  u  =  1  ft/s.  If  the  vehicle  is  travelling  at 
u  =  3  ft/s  the  control  law  is  too  fast  and  the  vehicle  makes  a  tighter  turn  than  it 
should.  We  want  a  controller  that  will  allow  the  vehicle  to  follow  the  exact  same  path 
regardless  of  its  speed.  The  solution  to  this  problem  is  to  perform  the  above  controller 
design  procedure  for  various  values  of  u  in  the  hopes  of  determining  a  relationship 
between  the  controller  gains  and  u.  If  this  relationship  can  be  found  then  a  nonlinear 
controller  design  can  be  obtained  with  controller  gains  properly  varying  as  a  function 
of  u.  The  second  problem  is  that  v,  r  and  VP  go  to  zero  in  steady  state  (5com  =  0).  It's 
desirable  to  have  v  and  r  go  to  zero,  but  VP  should  reach  some  commanded  heading 
OF  ) 

V  com/’ 

The  solution  to  the  first  problem  is  as  follows.  It  was  determined  that  k,  and 
k2  vary  inversely  proportional  to  u,  however,  changing  u  had  absolutely  no  effect  on 
k3.  The  second  problem  was  solved  simply  by  subtracting  VPcom  from  VP.  The  block 
diagram  of  the  PD  controller  is  shown  in  Figure  2.5.  Here  is  the  final  control  law: 


=  i(-0.3587<> -4.29 f)  -0.69490?  -  ?J 


The  inputs  to  the  controller  are  u,  ^ ^  and  'Pcom.  The  State  Estimator  block  of 
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Figure  2.1  provides  .q,  *  and  ^  .  The  commanded  heading  block  of  Figure  2.1 

provides  ^com.  The  controller  has  two  outputs;  one  for  the  bow  rudders  (5com)  and  one 
for  the  stem  rudders  (-5com). 

Commanded  heading  is  determined  by  a  switching  network  (Figure  2.6).  It  has 
a  Clock  input  which  controls  the  switches  to  allow  the  output  (xPcom)  to  change  at  the 
desired  time  during  the  simulation.  This  allows  the  steering  system  to  receive 
different  heading  commands  during  the  simulation. 

D.  STATE  ESTIMATOR  DESIGN 

The  design  of  the  state  estimator  followed  closely  the  design  of  the  PD 
controller.  The  equations  for  ^  and  ^  were  linearized  about  a  single  velocity 

and  then  placed  in 

the  following  state  space  estimator  form: 

x=Ax+Bh _ ,+Ie 

com  c\.) 

It  is  assumed  there  are  only  sensors  for  r  and  'P,  and  that  v  has  only  an  estimated 
value  (■£).  Therefore,  there  are  only  two  observer  errors  (eor  and  eo9).  Since  e0()  is  a 

2x1  matrix  the  observer  gain  matrix  (L)  must  be  3x2.  Linearization  was  done  about  u 
=  1  ft/s  and  pole  placement  was  performed  to  obtain  L.  Following  normal  convention 
the  observer  poles  were  placed  at  -0.4,  which  is  twice  the  distance  from  the  origin  as 
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the  controller  poles.  The  following  observer  gain  matrix  was  realized: 

[Lj,  L2;  L3,  L4;  Ls,  LJ  =  [1.2025,  0.0;  0.4219,  0.0;  1.0,  0.41] 

Again  there  is  the  problem  that  the  state  estimator  is  based  on  a  linear  model. 
If  the  vehicle  is  travelling  at  u  —  3  ft/s,  the  estimator  will  be  too  slow.  There  must  be 
a  relationship  between  u  and  L.  The  state  estimator  design  was  performed  using 
various  values  of  u,  and  it  was  determined  that  L2,  L4  and  L5  do  not  change  at  all  as  u 
is  changed.  However,  it  was  discovered  that  L,,  L3  and  L6  are  directly  proportional  to 
u.  The  State  Estimator  block  is  shown  in  Figure  2.7.  This  block  has  the  same  inputs 
as  the  steering  block  but  also  has  the  sensor  inputs  r  and  'P.  It  is  essentially  the  same 
block  as  the  steering  model  with  an  added  term  (Leo()).  The  outputs  are  the  estimated 
values  of  v,  r  and  (^,  f  and 

E.  FAILURE  MODE  INSERTION 

In  order  to  study  the  effects  of  various  failure  modes,  a  method  must  be 
installed  to  allow  failures  to  be  easily  inserted  into  the  simulation.  Steering  system 
failures  can  be  cataloged  into  two  basic  groups:  Rudder  failures  and  sensor  failures. 
Rudder  and  sensor  blocks  were  added  to  achieve  this  goal. 

1.  Rudder  Blocks 

Four  rudder  blocks  were  installed  (one  for  each  rudder  to  match  the  Phoenix 
configuration),  as  can  be  seen  in  Figure  2.1.  It  is  relatively  easy  to  modify  the 
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simulation  to  match  other  AUV  configurations  such  as  that  proposed  for  the  Navy's 
UUV.  The  diagram  of  a  rudder  block  is  shown  in  Figure  2.8,  and  it  can  be  seen  that 
it  is  a  switching  network  much  like  the  commanded  heading  block.  It  has  two  inputs, 
5com  and  Clock.  The  clock  input  is  used  to  control  the  switches  to  insert  a  failure  in 
5com  at  any  time  during  the  simulation.  It  is  capable  of  simulating  many  failures  such 
as  stuck  rudder,  hard  rudder,  loose  rudder  or  limited  rudder.  The  output  of  a  rudder 
block  is  either  the  ordered  rudder  position  or  the  failed  rudder  position. 

2.  Yaw  Rate  Sensor  Blocks 

Building  a  block  that  can  accurately  simulate  the  output  of  a  sensor  and  the 
output  of  a  failed  sensor  is  again  done  with  the  use  of  switches.  The  clean  output 
signal  is  picked  off  of  the  Steering  block  and  then  corrupted  with  noise.  The  noise  is 
added  to  make  the  simulation  more  realistic  since  no  sensor  can  provide  a  totally 
noise-free  output.  The  clean  signal  and  the  noise  each  have  their  own  sensor  block  to 
allow  one  of  them  to  be  modified  during  the  simulation  without  affecting  the  other. 
For  example,  a  signal  with  an  unusually  high  noise  level  could  be  simulated,  or  the 
noise  level  may  be  normal  but  the  signal  itself  is  incorrect.  Problems  that  could  occur 
with  a  sensor  besides  increased  noise  are:  saturation,  loss  of  input,  loss  of  output  and 
constant  bias. 

A  typical  sensor  noise  block  is  shown  in  Figure  2.9.  The  Clock  input  controls 
the  time  at  which  the  problem  of  high  sensor  noise  would  occur  (if  so  desired  in  the 
simulation).  Basically,  the  block  takes  the  noise  input  and  adjusts  its  level  for  output 
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to  be  added  to  the  clean  sensor  signal.  Figure  2.10  shows  a  sensor  signal  block.  It 
takes  the  clean  signal,  corrupts  it  and  sends  the  output  to  be  added  to  the  noise  signal. 


3.  Heading  Angle  Sensor  Blocks 

Obviously  the  primary  sensor  for  the  steering  system  is  the  heading  sensor,  and 
it  will  be  proven  later  that  any  failure  of  this  sensor  is  catastrophic.  Armed  with  this 
knowledge  the  Psi  sensors  block  was  added  to  Figure  2.1.  This  block  assumes  that 
since  the  heading  sensor  is  so  important  the  vehicle  will  be  equipped  with  three  of 
them.  It  is  shown  in  Figure  2.11.  It  has  three  sensor  and  three  noise  blocks  so  as  to 
simulate  a  problem  with  one  or  more  of  the  three  sensors  at  a  specified  time  using  the 
Clock  input.  The  other  two  inputs  are  the  clean  signal  (XF)  and  the  estimated  signal 
( i|r  Three  values  of  observer  error  (eoY),  one  for  each  sensor,  are  calculated.  These 


observer  errors  are  fed  into  a  function  (see  Appendix  C),  similar  to  a  median  filter, 
which  extracts  any  suspect  errors  and  averages  the  rest.  A  suspect  observer  error  is 
one  which  exceeds  a  certain  small  threshold.  The  threshold  is  simply  chosen  to  be 
slightly  greater  than  acceptable  noise  amplitudes.  This  is  because  during  normal 
steering  system  operation  e0>P  should  only  contain  zero  mean  noise.  In  the  case  of  all 
three  errors  being  suspect  (such  as  when  a  steering  system  failure  occurs)  the  function 
simply  averages  them  all.  The  output  of  this  block  is  the  average  eolf,  which  is  sent  to 
the  State  Estimator  block  of  Figure  2.1. 
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F. 


SUMMARY 


This  chapter  has  shown,  step  by  step,  how  an  FMEA  tool  was  designed  so  as 
to  study  the  NPS  Phoenix  AUV  steering  system.  Much  had  to  be  known  about  the 
dynamics  of  the  AUV  in  order  to  produce  a  working  simulator.  The  use  of  switches 
in  sink  with  a  running  Clock  helped  make  the  simulator  more  user  friendly.  The  user 
simply  has  to  change  the  settings  of  these  switches  to  create  the  desired  simulation.  If 
input  files  had  been  used  rather  than  switches,  the  user  would  have  to  edit  the  files 
every  time  the  simulation  was  changed.  It  has  been  noted  here  that  there  are  other 
ways  to  insert  failures  and  rudder  commands,  but  the  method  used  in  this  work  was 
deemed  to  be  the  easiest  to  understand  and  the  most  user  friendly.  The  remainder  of 
this  work  seeks  to  accomplish  a  thorough  analysis  of  the  Phoenix  AUV  steering 
system  using  the  newly  designed  FMEA  tool.  The  final  task  will  be  to  establish  an 
algorithm  that  can  be  incorporated  in  the  Phoenix  software  for  failure  detection  and 
resolution. 
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Figure  2.2  Geometry  and  Axes  Definitions  (Positive  Conventions  Shown). 
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Figure  2.3 


Steering  System  Model. 
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noise  1. mat  - ►0.001 


Figure  2.6  Commanded  Heading  Block. 
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Switch 


Figure  2.8  Rudder  Block. 


Switch 


Figure  2.9  Sensor  Noise  Block. 
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Figure  2.10  Sensor  Signal  Block. 
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Figure  2.11  Primary  Sensor  Auctioneering  and  Averaging  Block. 
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in.  PHOENIX  AUV  STEERING  SYSTEM  FAILURE  MODES  ANALYSIS 


A.  INTRODUCTION 

The  purpose  of  this  chapter  is  to  show  the  results  of  a  comprehensive  FMEA 
on  the  Phoenix  AUV  steering  system.  First  it  was  determined  what  types  of  failures 
could  occur  involving  the  steering  system.  Each  of  these  failures  was  then  simulated 
using  the  FMEA  tool  already  designed  (Chapter  II),  and  each  one  was  compared  to  the 
normal  (trouble  free)  response.  The  results  of  these  simulations  were  put  in  tabular 
form  from  which  they  could  be  studied  (for  similarities  and  trends)  and  further 
categorized.  These  studies  resulted  in  many  important  conclusions  involving  vehicle 
dynamics,  failure  detection  and  in  some  cases  failure  prevention.  Further  analysis 
helped  formulate  possible  solutions  to  the  failures.  The  end  result  is  an  algorithm 
which,  when  converted  to  the  proper  form,  can  be  incorporated  in  the  Phoenix 
software  for  failure  detection  and  resolution. 

B.  FAILURE  CATEGORIZATION 

In  analyzing  the  AUV  steering  system  it  was  determined  that  any  failure 
occurring  on  the  vehicle,  if  it  had  any  effect  on  the  steering  system,  could  be 
categorized  as  one  of  two  types: 

1.  Rudder  Failures 

2.  Sensor  Failures 
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There  are  five  possible  rudder  failures  that  can  occur: 


(1)  Loose  Rudder:The  rudder  in  question  will  not  respond  (stuck  at  zero).  For 
the  Phoenix  (which  has  four  rudders)  the  other  rudders  can  still  turn  the 
vehicle,  however  its  response  to  course  changes  will  be  slower. 

(2)  Stroke  Limited  Rudder:The  rudder  in  question  does  not  have  its  full  range 
of  motion.  As  in  the  loose  rudder  case,  the  vehicle  will  simply  respond  more 
slowly  to  course  changes. 

(3)  Stuck  RudderA  rudder  is  stuck  in  some  position  other  than  zero;  the 
special  case  of  a  rudder  stuck  at  zero  is  considered  in  this  work  as  a  loose 
rudder.  In  this  case  the  remaining  rudders  must  turn  to  counteract  the  yaw  rate 
caused  by  the  stuck  rudder.  Once  this  has  been  done  the  vehicle  will  no  longer 
be  heading  in  the  commanded  direction,  and  vehicle  response  to  further  course 
changes  will  be  slowed  as  in  the  loose  or  stroke  limited  cases. 

(4)  Hard  RudderA  rudder  is  stuck  in  the  hard  right  or  hard  left  position.  This 
is  simply  a  special  case  of  stuck  rudder. 

(5)  No  Rudder  Response:  All  rudders  are  stuck  at  zero.  In  this  case  the  vehicle 
steering  system  would  not  respond  at  all  to  commanded  course  changes. 


There  are  also  five  possible  sensor  failures.  Since  the  steering  system  has  two 
sensors  of  interest  these  failures  would  have  to  be  applied  to  each  sensor,  resulting  in 
ten  sensor  failure  modes.  The  five  possible  yaw  rate  sensor  failures  are  as  follows: 


(1)  Increased  Noise  LevekThe  more  noise  that  a  sensor  reads  the  harder  it  is 
to  determine  the  actual  value  of  the  parameter  being  measured.  This  is  a  very 
difficult  failure  to  detect.  The  intent  of  modelling  this  failure  is  to  show  that 
the  steering  system  can  operate  effectively  with  as  high  as  a  ten  fold  increase 
in  noise  level,  thus  eliminating  the  need  for  detecting  it. 

(2)  Loss  of  Input:In  this  case  the  state  estimator  will  only  receive  noise  from 
the  yaw  rate  sensor.  Since  the  steering  system  parameters  are  fully  observable 
with  the  heading  sensor  alone,  a  loss  of  the  yaw  rate  sensor  should  have  only  a 
small  effect  on  the  vehicle's  steering  system  performance.  Detecting  this 
failure  may  not  even  be  necessary. 
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(3)  Loss  of  Output:Once  the  increased  noise  level  scenario  is  proven  to  have  little 
effect,  the  results  of  this  failure  should  be  the  same  as  a  loss  of  input,  since  the 
state  estimator  is  getting  zero  from  the  sensor  rather  than  noise. 

(4)  Sensor  Saturation:The  state  estimator  gets  a  large  value  of  yaw  rate.  In  order 
to  reduce  the  controller  signal  to  the  rudders  to  zero  (so  the  vehicle  doesn't  go  in 
circles)  the  estimated  value  of  heading  will  be  incorrect.  The  result  of  this  failure 
should  be  a  large  change  in  heading  without  the  command  to  do  so. 

(5)  Sensor  Bias:The  bias  in  yaw  rate  will  cause  an  incorrect  estimate  of  heading 
as  in  the  saturated  sensor  case.  Again,  the  result  should  be  an  uncommanded 
heading  change.  The  amount  of  heading  change  will  depend  on  the  size  of  the 
bias. 


It  is  assumed  that  since  the  heading  sensor  is  the  primary  sensor  for  the  steering 
system,  failures  of  that  sensor  should  be  prevented.  However,  the  following  two  failure 
modes  were  studied  in  order  to  show  the  severity  of  such  failures  and  the  need  for 
prevention: 


(1)  Stuck  Heading  Sensor:With  a  stuck  heading  sensor  the  vehicle  would  respond 
to  course  changes  by  going  in  circles  because  it  would  never  reach  its  commanded 
heading. 

(2)  Heading  Sensor  Bias: With  a  heading  sensor  bias  the  vehicle's  course  would 
always  be  off  by  the  amount  of  the  bias.  This  failure  is  impossible  to  detect. 

The  actual  failures  studied  in  this  work,  along  with  a  complete  description  of  each 
failure's  simulation  scenario,  are  listed  in  Table  3.1.  It  should  be  noted  that  each 
simulation  starts  with  the  same  initial  heading  and  speed  (Y  =  0.0  rads,  u  =  3  ft/s). 

C.  PLACING  SIMULATIONS  IN  TABULAR  FORM 


Each  scenario  of  Table  3.1  was  performed  twice;  once  without  a  failure  and  once 
with  the  failure  inserted.  The  FMEA  results  are  displayed  in  Table  3.2.  The  first  column 
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of  Table  3.2  lists  the  failure  modes.  The  next  nine  columns  represent  the  signals  that 
would  be  available  to  the  AUV  for  analysis.  The  following  entries  appear  in  these 
columns: 


TST  -  No  difference  between  the  normal  and  failed  responses. 

'S'  -  A  steady  state  difference  exists  between  the  normal  and 

failed  responses. 

'T'  -  A  transient  difference  exists  between  the  normal  and 

failed  responses.  This  means  the  two  responses  coalesce 
in  steady  state,  making  detection  more  difficult. 

'I'  -  The  difference  between  the  normal  and  failed  responses 

increases  without  bound. 

Column  1 1  indicates  the  failure  severity  (FS).  Entries  include: 

'L'  -  Low:  failure's  effect  is  small;  no  correction  required. 

'M'  -  Medium:  failure's  effect  is  large  enough  to  require 

correction  such  as  sensor  removal,  gain  changes  and/or 
bias  insertions. 

'H'  -  High:  failure  is  not  correctable  or  the  AUV  can  not 

operate  effectively. 

The  last  column  in  Table  3.2  indicates  the  difficulty  of  detection  (DD).  Possible  entries 
are: 

'L'  -  Low:  can  be  detected  in  steady  state  using  available  signals. 
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'M'  -  Medium:  Since  the  normal  and  failed  responses  are  equal 

in  steady  state,  a  maneuvering  transient  is  required  for 
detection/verification  of  failure. 

'H'  -  High:  not  detectable. 

D.  DISCUSSION  OF  RESULTS 

In  order  for  the  AUV  to  be  able  to  detect  failures  and  respond  accordingly,  the 
following  questions  must  be  answered.  Can  all  the  possible  steering  system  failures  be 
detected?  In  other  words,  can  we  distinguish  between  a  failure  and  normal  operation? 
It  follows  that  if  all  failures  can  not  be  detected,  can  we  prevent  those  that  are 
invisible  to  the  AUV's  available  signals  and  sensors?  Finally,  is  it  possible  to 
distinguish  between  the  detectable  failures  so  that  proper  action  can  be  taken  in 
response?  The  answers  to  these  questions  will  become  apparent  in  the  remainder  of 
this  work. 

In  analyzing  Table  3.2,  it  can  be  assumed  that  any  failed  response  that  has  a 
steady  state  or  transient  difference  with  the  normal  response  can  be  detected.  A 
difference  that  increases  without  bound  is  considered  very  easy  to  detect.  Excluding 
two  of  the  failure  modes  (high  r  sensor  noise  and  bias  on  'F  sensor)  it  is  possible  to 
detect  and  distinguish  between  all  steering  system  failures  studied.  It  will  be  shown 
later  that  high  r  sensor  noise  does  not  have  a  large  enough  effect  on  the  vehicle  to 
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even  be  called  a  failure.  Also,  it  will  be  shown  that  preventing  *F  sensor  failures  is 
essential  for  proper  steering  system  operation. 

It  may  be  assumed  that  when  the  difference  between  the  failed  and  normal 
responses  is  steady  or  increasing,  there  is  a  failure.  The  system  then  has  only  to 
determine  the  exact  nature  of  the  failure  and  what  its  response  will  be.  But  what  if 
the  failure  only  shows  up  as  a  transient?  It  is  not  good  practice  to  assume  a  failure 
has  occurred  after  detecting  it  once  (false  alarms  do  happen).  Some  failures  require  a 
maneuver  to  verify  them,  because  their  normal  and  failed  responses  coalesce  after  the 
transient  is  over.  Once  such  a  failure  has  been  detected,  it  is  proposed  that  the 
maneuver  of  Figure  3.1  be  performed  for  verification.  It  is  also  suggested  that  this 
maneuver  be  executed  periodically,  whenever  the  vehicle  is  not  performing  any  course 
changes,  so  as  to  be  able  to  detect  one  of  these  failures  early  rather  than  when  the 
vehicle  is  in  a  critical  situation. 

One  more  thing  that  can  be  seen  from  Table  3.2  is  how  the  observer  errors 
respond  to  the  various  failure  modes.  It  should  be  noted  here  that  eor  and  e0^  are 
always  zero  unless  a  failure  has  occurred.  Figures  3.2  and  3.3  show  eor  vs  time  and 
e0vf  vs  time  respectively  for  the  maneuver  of  Figure  3.1.  The  only  variation  in  the  two 
signals  can  be  attributed  to  sensor  noise.  If  'F  sensor  failures  are  prevented  and  r 
sensor  noise  is  not  considered  a  failure,  then  eor  and  e0<f  alone  can  be  used  to 
determine  if  a  failure  has  occurred.  Any  non-zero  value  of  eor  or  e0>i,  can  indicate  there 
is  a  problem.  Of  course,  if  this  non-zero  value  was  just  a  transient  then  the  maneuver 
of  Figure  3.1  must  be  carried  out  to  verify  the  failure  actually  exists.  Once  it  has  been 
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determined  that  there  is  a  problem,  eor  and  eo¥  can  be  used  together  to  distinguish 
whether  a  rudder  problem  or  an  r  sensor  problem  exists.  If  a  rudder  problem  exists, 
only  eor  will  be  non-zero.  If  an  r  sensor  problem  exists,  both  eor  and  eoT  will  be  non¬ 
zero. 

E.  RUDDER  FAILURES 

1.  Loose  Rudder 

In  reality  a  loose  rudder  is  one  that  is  no  longer  coupled  to  its  servo 
mechanism  and  is  at  the  mercy  of  the  hydrostatic  forces  in  the  water.  It  is  assumed 
here  that  a  loose  rudder  is  one  that  is  stuck  at  zero.  We  could  even  call  this  a  special 
case  of  a  stuck  rudder.  The  steering  system  will  still  operate  with  a  loose  rudder,  but 
the  vehicle  dynamics  will  be  slowed  down.  In  other  words,  it  will  take  a  little  longer 
for  the  vehicle  to  perform  the  desired  course  change.  The  severity  of  this  failure  mode 
can  be  measured  by  the  magnitude  of  the  transient  of  eor. 

If  |  eor  |  <  0.05,  then  the  ship  will  still  be  within  one  ship  length  (7.3  ft)  of  its 
desired  track  after  the  completion  of  a  90  degree  turn,  thus  no  action  will  be  taken 
(failure  severity  is  low).  A  90  degree  turn  was  chosen  because  this  corresponds  to  the 
suggested  maneuver  of  Figure  3.1. 

If  0.05  <  |  eor  [  <  0.075,  then  a  90  degree  turn  will  result  in  the  vehicle  being 
off  its  course  by  more  than  one  ship  length  but  enough  rudder  response  remains  to 
correct  the  problem.  The  problem  is  corrected  by  increasing  the  magnitudes  of  the 
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controller  gains  in  order  to  speed  up  the  response  of  the  remaining  rudders.  This  has 
the  effect  of  speeding  up  the  already  slowed  dynamics  of  the  vehicle.  With  the 
controller  gains  changed  the  vehicle  can  perform  its  90  degree  turn  and  still  stay 
within  one  shiplength  of  its  desired  track. 

If  k,l  *  0.075,  then  the  failure  can  not  be  corrected  to  keep  the  vehicle 
within  one  ship  length  after  a  90  degree  turn.  This  would  be  cause  to  abort  the 
mission. 

In  the  loose  rudder  scenario  studied  in  this  work  both  bow  rudders  were  stuck 
at  zero.  Figures  3.4  and  3.5  show  eor  =  T  and  eoT  -N'.  Also,  the  magnitude  of  eor  is 
approximately  0.05.  Figure  3.6  shows  that  the  path  followed  by  the  vehicle  is  about 
one  ship  length  off  of  the  normal  path.  To  verify  that  the  observer  errors  are  correct, 
the  vehicle  can  check  its  individual  rudder  position  sensors.  Figure  3.7  shows  the 
upper  bow  rudder  to  be  stuck  at  zero.  This  failure  can  be  corrected  by  increasing  the 
controller  gains,  thus  speeding  up  the  vehicle's  turn. 

2.  Stroke  Limited  Rudder 

For  the  purposes  of  this  work  a  stroke  limited  rudder  is  one  that  no  longer  has 
its  full  range  of  motion.  This  could  be  caused  by  a  faulty  servo  mechanism  or  a 
foreign  object  physically  limiting  the  rudder's  travel.  Like  in  the  case  of  a  loose 
rudder,  the  steering  system  will  still  perform  its  job  but  vehicle  dynamics  will  again  be 
slowed  down.  The  exact  same  procedure,  as  in  the  loose  rudder  case,  is  used  to 
determine  the  severity  of  this  failure.  As  before,  the  correction  (if  required)  will  be  to 
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increase  the  controller  gains  to  speed  up  the  rudder  response.  However,  if  |  eor  |  > 
0.075  then  there  is  not  enough  rudder  control  remaining  to  correct  the  problem  and 
allow  the  AUV  to  operate  effectively. 

In  the  scenario  studied  here,  both  stem  rudders  are  limited  to  ±0.2  rads. 

Figures  3.8  and  3.9  show  eor  =  T'  and  e0^,  -N'.  Since  I  eor|  <  0.05  this  failure  is 
considered  tolerable  and  a  correction  is  not  made.  The  vehicle  is  only  off  course  by  a 
few  feet  as  seen  in  Figure  3.10.  Had  this  failure  been  more  serious  and  corrective 
action  necessary,  it  could  be  verified  that  the  observer  errors  were  correct  by  checking 
individual  rudder  position  sensors  as  in  the  loose  rudder  case.  Figure  3.11  shows  that 
the  upper  stem  rudder  was  limited  to  0.2  rads  rather  than  saturating  at  0.4  rads  as  it 
should  have  if  it  had  its  full  range  of  motion. 

3.  Stuck  Rudder 

A  rudder  is  stuck  if  it  will  not  move  regardless  of  the  signals  sent  to  the  servo 
mechanism.  This  can  be  caused  by  some  foreign  object  preventing  the  rudder's 
movement,  or  maybe  the  commanded  rudder  signal  simply  is  not  getting  to  the  servo 
to  change  the  rudder's  position.  Since  the  normal  and  failed  responses  of  nearly  all  the 
signals  studied  in  this  work  show  a  definite  difference  in  steady  state,  no  maneuver  is 
required  to  verify  it.  However,  the  actions  required  are  a  little  more  complicated  than 
in  the  loose  or  stroke  limited  cases;  and  a  maneuver  will  be  required  anyway  to  ensure 
the  vehicle  can  still  operate  effectively. 
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The  way  to  combat  this  failure  is  to  first  get  the  vehicle  pointed  in  the  right 
direction  again.  This  is  done  by  adding  a  bias  to  'Fcom  that  will  account  for  the  servo 
error.  This  bias  is  the  only  one  that  is  added  to  affect  a  change  in  the  vehicle's 
subsystems.  Other  bias  signals  must  be  added  for  the  purpose  of  removing  the  steady 
state  differences  between  the  normal  and  failed  responses  so  that  the  steering  errors  are 
compensated.  For  example,  the  controller  will  still  receive  ^  from  the  state  estimator, 

however  the  failure  detection  software  will  get  V)+-y  •  Other  signals  besides  ^ 

v  vbias 

that  require  bias  additions  are  *  (this  resets  eor)  and  es.  Now,  as  in  the  loose  or  stroke 

limited  cases,  the  steering  system  dynamics  have  been  slowed  because  the  remaining 
rudders  are  compensating  for  the  stuck  rudder.  So  again  the  maneuver  of  Figure  3.1 
must  be  executed  to  see  if  the  controller  gains  must  be  raised  to  allow  the  vehicle  to 
respond  fast  enough.  In  some  extreme  stuck  rudder  cases  |  eor  I  >  0.075,  at  which 
point  the  mission  must  be  aborted. 

In  the  stuck  rudder  scenario  from  Table  3.1,  eor  =  'S'  and  e0<i,  ='N'  (Figures  3.12 
and  3.13).  Individual  rudder  sensors  must  be  used  to  verify  that  the  observer  errors 
are  not  incorrect  and  to  ensure  that  the  wrong  failure  is  not  being  evaluated.  The 
signals  that  the  AUV  would  analyze  in  the  case  of  no  rudder  response  are  similar  to 
the  stuck  rudder  case,  except  for  the  rudder  position.  Figure  3.14  shows  the  upper 
stem  rudder  is  stuck.  The  next  thing  to  check  is  the  servo  error;  if  it  is  increasing 
without  bound  then  the  vehicle  can  not  correct  the  stuck  rudder  problem  using  the 
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other  rudders  and  the  mission  would  be  aborted.  In  this  case,  however,  servo  error 
does  not  increase  without  bound  (Figure  3.15).  Now  the  vehicle  must  be  pointed  in 
the  right  direction  and  the  proper  biases  must  be  inserted.  Then  the  maneuver  of 
Figure  3.1  must  be  performed  to  determine  if  controller  gain  change  is  required.  In 
this  case  |  eor  |  <  0.05  (see  Figure  3.12),  so  no  gain  changes  are  necessary.  The 
vehicle's  path  for  this  scenario  is  shown  in  Figure  3.16. 

4.  Hard  Rudder 

Simply  put,  a  hard  rudder  is  just  a  special  case  of  a  stuck  rudder.  In  this  case 
the  rudder  is  stuck  at  an  angle  of  ±0.4  rads  (the  maximum  rudder  angle  allowed).  It 
can  be  caused  by  the  same  things  that  created  the  stuck  rudder.  It  can  also  be  caused 
by  a  wire  that  has  shorted  itself  to  some  source  of  voltage  that  would  then  saturate  the 
signal  going  to  the  servo  mechanism.  Since  this  is  still  a  stuck  rudder  case  the 
indications  are  the  same;  and  the  actions  required  to  combat  the  failure  are  identical  to 
those  of  the  stuck  rudder  case. 

In  the  scenario  studied  here  (Table  3.1)  both  stem  rudders  are  stuck  hard  at  0.4 
rads.  Again  it  is  shown  that  eor  =  'S'  and  e0<f  ='N'  (Figures  3.17  and  3.18),  as  in  the 
stuck  rudder  case.  Rudder  sensors  are  checked  to  ensure  the  observer  errors  are 
correct  and  that  it  is  not  a  'no  rudder  response'  case.  The  servo  error  is  then  checked 
(Figure  3.19)  and  it  is  found  to  be  increasing  without  bound.  This  makes  sense 
because  the  stem  rudders  have  a  larger  effect  on  vehicle  steering  than  the  bow  rudders. 
This  is  due  to  the  larger  moment  arm  of  the  stem  rudders,  since  they  are  located 


37 


further  from  the  center  of  gravity  than  the  bow  rudders.  The  mission  must  be  aborted 
since  the  vehicle  can  only  go  in  circles  (Figure  3.20). 

5.  No  Rudder  Response 

In  this  case  none  of  the  rudders  move  in  response  to  a  commanded  course 
change.  This  could  happen  if  all  four  rudders  were  simultaneously  stuck  at  zero  or  if 
5com  =  0  due  to  a  wire  being  shorted  to  ground.  In  the  scenario  of  Table  3.1  the 
vehicle  first  detects  that  eor  =  'S'  and  eoy  ='N'  (Figures  3.21  and  3.22).  The  rudder 
sensors  are  then  checked  and  it  is  found  that  they  are  all  stuck  at  zero.  Figure  3.23 
shows  the  upper  stem  rudder  response  and  it  is  in  fact  stuck  at  zero.  Also,  the  vehicle 
continues  to  move  in  the  same  direction  despite  the  commanded  course  change  (Figure 
3.24).  The  wiggle  of  Figure  3.1  can  be  attempted  to  see  if  maybe  this  is  a  temporary 
condition,  but  if  no  response  is  noted  by  the  rudders  the  mission  must  be  aborted. 

F.  YAW  RATE  SENSOR  FAILURES 

1.  Increased  Yaw  Rate  Sensor  Noise 

Many  different  types  of  interference  can  increase  sensor  noise.  The  worst  kind 
of  interference  can  come  from  jamming,  which  is  very  possible  if  the  AUV  is  used  for 
military  purposes  such  as  mine  countermeasures.  In  this  work  a  90  degree  heading 
change  was  ordered  while  the  r  sensor  experienced  a  noise  increase  by  a  factor  of  ten. 
From  Figure  3.25  it  can  be  seen  that  the  vehicle's  path  was  nearly  unaffected  by  the 
increased  noise.  It  is  therefore  assumed  that  a  noise  increase  in  the  r  sensor  does  not 
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constitute  a  failure  and  the  detection  software  will  not  even  consider  it  an  option  when 
conducting  failure  analysis. 

2.  Loss  of  Yaw  Rate  Sensor 

If  the  vehicle  experiences  a  loss  of  r  sensor  input,  the  state  estimator  will 
simply  receive  sensor  noise.  Similarly,  if  the  entire  sensor  is  lost  (no  output)  the  state 
estimator  will  receive  an  input  of  r  =  0.  Both  cases  are  lumped  into  one  here  since  the 
sensor  noise  has  little  effect  anyway.  In  the  scenario  found  on  Table  3.1,  the  loss  of 
input  to  the  r  sensor  is  used  to  study  this  failure.  Figure  3.26  shows  that  by  losing  the 
r  sensor  the  vehicle  can  still  operate  effectively.  Given  a  90  degree  turn  it  is  off 
course  by  only  about  six  feet  (less  than  a  ship  length).  Therefore,  this  is  not  a  failure 
that  even  needs  to  be  accounted  for  by  the  detection  software.  However,  we  now 
know  that  if  a  more  severe  failure  occurs  in  the  r  sensor,  the  solution  will  be  to  ignore 
the  sensor's  output  and  call  it  zero. 

3.  Saturated  Yaw  Rate  Sensor 

A  saturated  r  sensor  could  occur  when  there's  a  short  in  the  sensor  circuit.  The 
severity  of  this  failure  on  the  vehicle's  path  can  be  seen  in  Figure  3.27.  To  determine 
this  failure  has  occurred  the  vehicle  circuitry  would  detect  that  eor  =  'S'  and  eo4,  -  S' 
(Figures  3.28  and  3.29).  It  can  be  verified  that  the  observer  errors  are  accurate  by 
checking  that  there  is  a  steady  state  es  (Figure  3.30)  while  5com  steadies  out  to  zero 
(Figure  3.31).  The  response  to  this  failure  is  to  ignore  the  r  sensor  output  and  set  it  to 
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zero.  This  is  the  chosen  action  since  it  has  already  been  shown  that  the  vehicle  can 
operate  effectively  without  the  sensor. 

4.  Bias  On  Yaw  Rate  Sensor 

The  effect  on  the  vehicle's  path  of  a  bias  on  the  r  sensor  is  shown  in  Figure 
3.32.  Again  eor  =  'S'  and  e0y  —S'  (Figures  3.33  and  3.34).  As  in  the  saturated  sensor 
case,  verification  can  be  obtained  by  showing  that  there  is  a  steady  state  es  (Figure 
3.35)  while  5com  steadies  out  to  zero  (Figure  3.36).  The  proper  response  would  be  to 
operate  without  the  sensor,  as  was  done  in  the  saturated  case. 

G.  HEADING  ANGLE  SENSOR  FAILURES 

The  study  of  VF  sensor  failures  is  simple  and  straight  forward.  The  T  sensor  is 
the  primary  sensor  of  the  steering  system,  so  its  importance  can  not  be 
overemphasized.  Since  it  is  desired  that  failures  not  occur  with  this  sensor,  it  is 
proposed  that  the  vehicle  be  supplied  with  three  of  them.  This  does  not  mean  three 
separate  inertial  units  are  required;  magnetic  compasses  are  low  cost  and  reasonably 
accurate.  When  one  sensor  fails  there  will  still  be  two  more  to  supply  the  correct 
heading.  The  two  failure  modes  studied  in  this  work  were  chosen  to  show  the 
importance  of  having  three  sensors.  With  this  in  mind,  there  will  be  no  discussion  as 
to  how  it  will  be  detected  or  what  actions  will  be  taken.  With  three  sensors  on  board 
it  will  be  assumed  that  failures  of  the  sensor  will  not  occur. 
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With  a  stuck  *F  sensor  the  vehicle  can  not  measure  its  heading  (knowing  only 
one  direction).  As  soon  as  a  'Feom  other  than  the  stuck  position  of  'F  is  ordered  the 
vehicle  will  simply  move  around  in  circles  (Figure  3.37).  This  would  be  difficult  to 
detect  and  correct  since  es  (Figure  3.38)  and  r  (Figure  3.39)  contradict  each  other.  The 
constant  es  would  indicate  the  vehicle  is  traveling  in  a  straight  line,  but  the  constant  r 
indicates  it  is  moving  in  a  circle. 

An  unknown  sensor  bias  added  to  'F  would  cause  the  vehicle  to  move  in  the 
wrong  direction.  It  would  alter  the  AUV's  course  by  an  amount  equal  to  (Figure 
3.40).  What  is  even  worse  than  this  is  the  fact  that  this  failure  mode  is  completely 
undetectable.  Figures  3.41  through  3.44  show  eor,  eoT,  es  and  5con,,  respectively.  The 
only  significant  difference  between  the  normal  and  failed  responses  occurs  at  five 
seconds  when  the  bias  is  inserted.  Once  the  bias  is  inserted,  the  normal  and  failed 
responses  are  identical.  If  the  bias  already  existed,  it  would  not  be  detected. 

Similarly,  if  the  occurrence  of  the  bias  was  caught  it  would  not  be  able  to  verify  it.  It 
is  possible  that  a  problem  like  this  could  be  noted  on  successive  navigational  fixes,  but 
then  the  system  would  have  to  be  able  to  distinguish  between  'Fbias  and  normal  set  and 
drift. 

H.  SUMMARY 

It  must  be  noted  here  that  when  the  AUV  controller  detects  a  failure  and 
responds  accordingly,  it  does  not  necessarily  know  the  exact  nature  of  the  failure.  For 
example,  whether  the  r  sensor  is  saturated  or  has  a  bias  is  not  a  concern.  The  system 
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need  only  know  that  there  is  an  r  sensor  problem  so  that  its  value  can  be  ignored  and 
set  to  zero  for  the  estimator.  Similarly,  the  procedure  used  to  correct  a  rudder  failure 
seeks  only  to  ensure  the  vehicle  can  operate  effectively.  It  does  not  care  which  rudder 
is  actually  causing  the  problem.  This  extra  information  can  be  determined  when  the 
mission  is  over  and  the  vehicle  can  be  tested. 

In  this  chapter  a  comprehensive  FMEA  was  conducted  on  the  Phoenix  AUV 
steering  system.  Several  possible  failure  modes  were  analyzed.  The  results  of  these 
analyses  provide  methods  to  detect  the  various  failures  and  what  to  do  when  they 
occur.  These  results  have  been  ordered  into  a  useful  algorithm  to  be  incorporated  in 
the  AUV's  software  for  failure  detection  and  resolution.  This  algorithm  has  been 
included  in  this  work  as  Appendix  D. 

Remember  that  this  chapter  deals  only  with  the  steering  system.  The  algorithm 
of  Appendix  D  would  obviously  be  running  in  conjunction  with  other  failure  detection 
algorithms.  For  example,  there  should  also  be  algorithms  for  the  propulsion  and 
diving  systems.  It  is  a  fact  that  when  there  is  a  stuck  rudder  (and  the  other  rudders 
are  turned  to  make  up  for  this)  the  drag  from  the  rudders  will  slow  the  vehicle  down. 
Also,  the  act  of  conducting  a  turn  will  slow  down  the  vehicle.  Speed  was  not 
considered  to  be  a  signal  monitored  by  the  steering  system.  However,  the  propulsion 
system  could  be  used  to  distinguish  between  a  stuck  rudder  and  no  rudder  response, 
rather  than  measuring  all  the  individual  rudder  position  sensors.  A  reduction  in  speed, 
as  sensed  by  the  propulsion  system,  could  indicate  the  rudders  have  moved.  Finally, 
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in  the  case  of  a  rudder  failure  (such  as  a  stuck  rudder),  the  propulsion  system  may  also 
need  to  take  action,  such  as  increasing  propeller  rpm's  to  maintain  speed. 

The  last  issue  needing  some  attention  is  the  action  taken  when  the  failure 
detection  system  is  not  working  properly.  What  happens  if  the  detection  system  reads 
a  combination  of  signals  that  it  can  not  map  to  a  specific  failure  mode?  The  worst 
case  must  always  be  assumed.  In  this  case  it  must  be  assumed  that  the  failure 
detection  system  is  not  working  properly.  Therefore,  if  a  failure  occurs  it  may  not  see 
it.  There  can  only  be  one  solution  to  this  dilemma:  abort  mission. 
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Table  3.1  Failure  Scenarios 


Failure  Mode 

Failure  Scenario 

Loose  rudder 

Ycom  changed  to  -1.571  rads  at  5  seconds. 

5urb  and  6]rb  stuck  at  zero 

Stroke  limited  rudder 

Ycom  changed  to  -1.571  rads  at  5  seconds. 

6urs  and  8lrs  limited  to  +  0.2  rads 

Stuck  rudder 

Ycom  changed  to  -1.571  rads  at  30  seconds. 

5urs  stuck  at  0.2  rads  at  5  seconds 

Hard  rudder 

5urs  and  8)rs  go  hard  over  to  0.4  rads  at  5  seconds 

No  rudder  response 

Ycom  changed  to  -1.571  rads  at  5  seconds. 

All  rudders  stuck  at  0.0  rads 

Increased  r  sensor  noise 

Ycom  changed  to  -1.571  rads  at  30  seconds. 

Sensor  noise  increased  1  OX  throughout  simulation 

Loss  of  input  to  r  sensor 

Ycom  changed  to  -1 .571  rads  at  5  seconds. 

No  sensor  input  (reading  noise  only) 

Saturated  r  sensor 

Sensor  saturates  (r  =  0.873  rad/s)  at  5  seconds 

Bias  on  r  sensor 

Ycom  changed  to  -1.571  rads  at  20  seconds. 

Bias  of  0.2  rad/s  inserted  at  5  seconds 

Stuck  Y  sensor 

Ycom  changed  to  -0.524  rads  at  5  seconds. 

Sensor  stuck  at  0.0  rads 

Bias  on  Y  sensor 

Ycom  changed  to  -1.571  rads  at  30  seconds. 

Bias  of  0.2  rads  inserted  at  5  seconds 

44 


Bias  on  Y  sensor 

Stuck  Y  sensor 

1 

Saturated  r  sensor 

Loss  of  input  to  r 

sensor 

Increased  r  sensor  noise 

No  rudder  response 

Hard  rudder 

Stuck  rudder 

Stroke  limited  rudder 

Loose  rudder 

Failure  Mode 

Z 

Z 

c o 

CO 

H 

Z 

CO 

CO 

CO 

H 

H 

o 

z 

c o 

GO 

CO 

H 

Z 

z 

z 

z 

z 

z 

o 

z 

CO 

CO 

CO 

H 

z 

CO 

CO 

H 

H 

tf) 

z 

c o 

H 

H 

H 

z 

CO 

CO 

00 

H 

H 

O? 

n 

o 

3 

z 

CO 

CO 

CO 

H 

z 

CO 

CO 

CO 

H 

H 

z 

00 

CO 

CO 

H 

z 

H 

CO 

H 

H 

H 

z 

CO 

CO 

CO 

H 

z 

CO 

- 

CO 

H 

H 

KE? 

z 

00 

CO 

00 

H 

z 

CO 

h— 4 

CO 

H 

H 

z 

00 

CO 

00 

H 

z 

CO 

CO 

00 

H 

H 

<> 

X 

X 

£ 

£ 

r 

r 

X 

X 

2 

r 

s 

CO 

X 

"  '  1 

r 

r 

2 

X 

r 

r* 

r 

£ 

2 

DD 

45 


TABLE  3.2  FMEA  RESULTS 
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Figure  3,1  Vehicle  Position  Plot  for  a  Typical  Maneuver 
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Figure  3.3  Typical  Maneuver  (e0^  vs  time). 
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Figure  3.6  Loose  Rudder  (Position  Plot). 
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Figure  3.7  Loose  Rudder  (5^  vs  time). 


Figure  3.8  Stroke  Limited  Rudder  (eor  vs  time) 
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Figure  3.9  Stroke  Limited  Rudder  (eo4,  vs  time). 
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Figure  3.13  Stuck  Rudder  (eolf, 
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Figure  3.16  Stuck  Rudder  (Position  Plot). 
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Figure  3.22  No  Rudder  Response  (eoV  vs  time). 
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Figure  3.30  Saturated  r  Sensor  (es  vs  time). 


Figure  3.32  Bias  on  r  Sensor  (Position  Plot)- 
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Figure  3.40  Bias  on  Sensor  (Position  Plot). 
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IV.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

It  has  been  shown  here  that  SIMULINK  can  be  used  to  design  an  effective 
FMEA  tool.  The  steering  system  of  the  Phoenix  AUV  was  modeled  and  used  to 
simulate  possible  associated  failure  modes.  The  problem  of  inserting  failures  was 
solved  through  the  use  of  switches  that  were  actuated  by  a  running  clock  during  the 
simulations.  These  switches  made  the  simulator  more  user  friendly,  allowing  the 
scenario  of  any  simulation  to  be  easily  changed  at  will. 

Through  intensive  study  it  was  found  that  observer  errors  could  be  used  to 
determine  if  a  failure  has  occurred.  These  observer  errors  can  also  be  used  to 
determine  the  type  of  failure  that  has  occurred  (rudder  or  sensor).  Other  signals 
available  to  the  AUV  are  used  to  verify  these  findings.  It  was  also  determined  that 
rudder  failures  are  far  more  complex  to  analyze  and  resolve  than  sensor  failures.  Also, 
since  some  failures  can  only  be  detected  during  a  heading  change,  it  was  decided  that 
a  maneuver  must  be  executed  to  verify  these  failures.  This  maneuver  would  also  be 
performed  periodically  when  the  vehicle  is  travelling  in  a  straight  line,  thus  allowing  it 
to  essentially  verify  every  now  and  then  that  everything  is  operating  properly. 

When  a  loose  or  stroke  limited  rudder  occurs  vehicle  dynamics  will  be  slowed. 
The  magnitude  of  eor  can  be  used  to  measure  the  severity  of  the  failure.  If  it  is  low, 
no  corrective  action  is  needed.  However,  certain  failures  will  require  that  the 
controller  gains  be  increased  to  speed  up  the  response  of  the  operable  rudders;  still 
other  cases  will  require  that  the  mission  be  aborted. 
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The  occurrence  of  a  stuck  rudder  (hard  rudder  included)  requires  that  we  check 
es  first.  If  it  is  not  increasing  without  bound,  then  the  vehicle  may  be  able  to  correct 
the  problem,  otherwise  it  must  abort  the  mission.  To  correct  this  problem  a  bias  is 
added  to  so  as  to  get  the  vehicle  pointed  in  the  right  direction  again.  Biases  are 
added  to  various  other  signals  to  compensate  for  their  errors.  Now  the  vehicle 
responds  as  though  it  has  a  loose  or  stroke  limited  rudder,  and  the  procedures 
governing  those  failures  must  now  be  followed. 

When  there  is  no  rudder  response  the  steering  system  can  not  perform  its 
function,  therefore  the  mission  must  be  aborted.  To  the  failure  detection  system  no 
rudder  response  looks  a  lot  like  a  stuck  rudder.  For  this  reason  the  individual  rudder 
position  sensors  must  be  checked  to  verify  the  correct  failure  before  taking  corrective 
action. 

Yaw  rate  sensor  failures  are  more  cut  and  dry  than  rudder  failures.  Increased 
sensor  noise  and  loss  of  sensor  do  not  affect  the  vehicle  enough  to  even  be  called 
failures,  therefore  they  do  not  need  to  be  watched  for.  However,  the  fact  that  a  loss  of 
r  sensor  will  not  adversely  affect  the  vehicle  makes  it  easy  to  respond  to  any  other  r 
sensor  failures.  If  the  sensor  incurs  a  bias  or  becomes  saturated,  the  solution  is  simply 
to  ignore  it  and  use  a  value  of  zero  for  the  estimator. 

Since  the  *F  sensor  is  the  primary  sensor  of  the  steering  system,  it  was  assumed 
and  later  proven  that  preventing  failures  was  the  better  way  to  go  than  trying  to  detect 
and  correct  them.  By  providing  the  AUV  with  three  auctioneered  sensors,  it  can  be 
assumed  that  failures  associated  with  'F  will  not  happen. 
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Finally,  to  sum  up  all  the  results  obtained  in  this  work  dealing  with  detecting 
and  correcting  failures,  an  algorithm  was  developed  (Appendix  D).  This  algorithm 
needs  only  to  be  converted  into  a  useful  format  for  insertion  into  the  AUV  tactical 
level  software  for  testing. 

B.  RECOMMENDATIONS 

The  FMEA  tool  that  has  been  designed  here  is  capable  of  simulating  the 
occurrence  of  any  failure  mode.  The  results  of  the  simulation  can  then  be  compared  to 
a  normal  response.  This  is  the  scope  of  what  the  tool  can  do.  It  is  recommended  that 
before  the  algorithm  of  Appendix  D  be  tested  on  the  vehicle,  it  should  be  tested 
through  simulation.  The  simulator  should  be  run  in  conjunction  with  the  algorithm, 
however  the  simulator  must  be  modified  to  be  able  to  take  the  proper  corrective 
actions  as  determined  by  the  algorithm.  Once  the  validity  of  the  algorithm  has  been 
proven  through  simulation,  it  can  then  be  loaded  into  the  AUV's  software  and  tested  in 
a  real  environment. 

It  is  also  recommended  that  the  analyses  done  in  this  work  be  done  to  the  other 
Phoenix  subsystems,  such  as  propulsion  and  diving  systems.  Also,  once  an  algorithm 
exists  for  each  subsystem  of  the  AUV,  they  must  be  coupled  to  work  together  in 
keeping  the  vehicle  operational.  For  example,  the  propulsion  system  is  affected  by 
rudder  changes.  The  analyses  done  on  the  steering  system  assume  that  speed  is  kept 
constant  by  the  propulsion  system. 
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Finally,  the  simulator  designed  in  this  work  assumes  that  only  r  and  'F  are 
measured,  therefore  v  only  has  an  estimated  value.  Since  we  know  that  v  can  be 
measured  using  the  doppler  sonar,  the  simulator  could  be  redesigned  to  include  a 
measured  v.  It  may  be  beneficial  to  perform  the  FMEA  with  a  measured  v.  On  the 
other  hand,  the  addition  of  another  sensor  adds  another  set  of  possible  sensor  failures, 
and  it  has  already  been  proven  that  the  steering  system  can  operate  effectively  with  the 
*P  sensor  alone. 
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APPENDIX  A.  CONSTANTS  AND  COEFFICIENTS  FROM  BAHRKE  (1992) 


Constant/Coefficient 

Value 

r, 

-0.00178 

r* 

-0.03430 

Yr 

0.0 

Yv 

-0.10700 

y5 

0.01180 

Nt 

-0.00047 

N, 

-0.00178 

Nr 

-0.00390 

Nv 

0.0 

I2  (ft4) 

45.0 

m  (slugs) 

13.5202 

L  (feet) 

7.3 

p  (slugs/ft3) 

1.94 

xG  (feet) 

0.0104 
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APPENDIX  B. 


MATLAB  PROGRAM  USED  TO  GENERATE  SYSTEM 
NOISE  FOR  INCORPORATION  INTO  THE  VEHICLE 
STEERING  SYSTEM  MODEL  (OBTAINED  FROM 
PROFESSOR  HEALEY) 


h=8  ; 

W= [0.3:0.05:2]  ; 
dw=  0.05; 

[l,m]=size(w)  ; 

S= W; 

for  i  =  l : m 

S(i)=8.1e-3*32.2A2/(w(i)/v5)  *exp(-33  .  56/h"2/  (w(i)  A4)  ) 
end; 

ws=  [0  . 3:0.05:2]; 
t=[0:0. 1:100] ; 

Y=zeros ( 1 , length ( t ) ) ; 

for  i=l : length (ws ) ; 
phi=rand ( 1 , length (ws ) ) ; 
phi =phi -mean (phi ) ; 

y ( i  ,  : )  =  ( sqrt ( S ( i ) *2  *dw)  ) *  cos (ws ( i ) *  t+phi ( i ) *pi *2 )  ; 
end; 

for  j =1 : length (ws ) ; 

Y=Y^y (j,:); 

end; 

Z  Z  =  [  t ;  Y  ]  ; 
save  noise3  ZZ; 
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APPENDIX  C. 


MATLAB  FUNCTION  USED  TO  AUCTIONEER  AND 
AVERAGE  THREE  OBSERVATION  ERRORS 


function  [uu]  =  sensor (u) ; 

eps=0 . 01 ; 
x=3  ; 

uu=u  ( 1 )  +u  ( 2  )  +u.(  3  )  ; 

if  abs (u ( 1 ) ) >=eps 

uu=uu-u ( 1 ) ; 
x=x-l  ; 

end; 

if  abs (u ( 2 ) ) >=eps 

uu=uu-u ( 2  )  ; 

X— X—  1  : 

end; 

if  abs (u ( 3 ) ) >=eps 

uu=uu-u ( 3 ) ; 
x=x-l ; 

end  ; 


if  x==0 

else 

end; 


uu= ( u ( 1 ) +u ( 2 ) +u ( 3 ) ) / 3 ; 
uu=uu / x ; 
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APPENDIX  D.  PROPOSED  ALGORITHM  FOR  LINKING  CORRECTIVE 

ACTIONS  TO  DETECTED  FAILURE  EFFECTS 

This  algorithm  is  based  on  the  following  set  of  possible  corrective  actions: 

-  abort  mission 

-  maneuver  execution 

-  bias  insertions 

-  ignore  sensor  output 

-  change  controller  gains 

1 .  if  eor  =  'N'  and  e0<J,  =  'N'  then 

goto  7 

endif 

2.  if  eor  =  T  or  e0>P  =  T  then 

eor  =  'N1  and  e0<F  =  'N' 

execute  maneuver  to  verify  failure  and  measure  I  eor  I 
if  eor  =  ’N'  and  e0*  =  'N'  then 
goto  7 
endif 

endif 

3.  if  eor  =  'S'  and  e0<i,  =  'N'  and  all  5,  =  0  (i  =  1,4)  then 

abort  mission 

endif 

4.  if  eor  =  'S'  and  eoT  =  'N'  and  any  8;  &  5com  (i  =  1,4)  then 

if  es  =  T  then 
abort  mission 
endif 

add  bias  to  vPcom  so  that  the  vehicle  will  head  in  the  right  direction 
add  biases  to  ^  *  and  es  in  order  to  equate  the  normal  and  failed 

responses  execute  maneuver  to  measure  |  eor  | 

endif 

5.  if  eor  =  'S'  and  e0>P  =  'S'  and  es  =  'S'  and  5com  — >  0  then 

ignore  the  output  of  the  r  sensor 

endif 
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6. 


if  eor  =  T  and  e0<},  =  'N'  and  any  5;  *  5com  (i  =  1,4)  then 
if  0.05  <  |  eor  |  <  0.075  then 

change  controller  gains  to  speed  up  rudder  response 
endif 

if  |  eor  |  >  0.075  then 
abort  mission 
endif 

endif 

7.  end  of  algorithm 
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